1. Technical Field
The present invention relates to data processing systems and, in particular, to application integration. Still more particularly, the present invention provides a method, apparatus, and program for testing application integration in a data processing system.
2. Description of Related Art
Application integration systems allow a company's applications to operate together. A main task of application integration is translating data and commands from the format of one application into the format of another application. Application integration is essentially data and command conversion on an on-going basis between two or more incompatible systems. Implementing application integration has traditionally been done by tedious programming. However, the trend today is to use message brokers, applications servers, and other specialized integration products that provide a common connecting point.
Most application integration systems may be classified as either point-to-point or hub-and-spoke systems. A traditional point-to-point integration scheme comprises a plurality of applications and a piece of integration code, also known as “middleware,” for every two applications that must operate together. Prior art FIG. 1 illustrates an example point-to-point integration model. Application 110 and application 120 operate with one another. Integration logic 115 is provided to translate data and commands from the format of application 110 into the format of application 120 and vice versa. For small systems with a small number of applications, point-to-point integration may be used. However, as the number of applications increases, the number of pieces of integration code may grow exponentially. Thus, a point-to-point integration scheme may become unwieldy and is not easily extendible.
The hub-and-spoke integration scheme includes a hub of integration logic and several spokes. Typically, an application resides in each spoke and performs a function within the integration model. For example, a billing application may reside in one spoke and a customer database application may reside in another spoke. Because each application may be written independently without anticipating that the application will be integrated with other specific applications, the data models and interfaces may not agree. In other words, an application may expect data to be received in a first format while other applications in the system may output information in a second format. Adapter logic is provided between each application and the hub to convert or translate data so that each application receives data in an expected format.
With reference to prior art FIGS. 2A-2C, an example hub-and-spoke integration model is depicted. As shown in FIG. 2A, application 210 is connected to hub 202 by adapter 215. Similarly, application 220 is connected to hub 202 by adapter 225; application 230 is connected to hub 202 by adapter 235; and, application 240 is connected to hub 202 by adapter 245. The number of applications may vary depending upon the implementation.
Conventionally, the hub 202 consists of a generic business object model, such as generic business objects 204, a transformation engine that maps application specific objects (not shown) to generic business objects 204 and vice versa, and a collaboration engine (not shown) that executes any process logic that is part of synchronizing the hub-and-spoke integration scheme. The generic business object model describes data that is used by all applications. This is in contrast to an application specific business object model, which is specific to one given application. The transformation engine is described in more detail below with reference to FIG. 2B.
One skilled in the art will readily recognize that mappings 206 document how application specific objects map to generic business objects 204 and vice versa. When data is sent from a first application to a second application, a data object must first be converted (mapped) from the format of the first application to the generic business object model. Then, the data object must be mapped from the generic business object format to the application specific business object format of the second application. Mappings 206 are conventionally created by a developer with a priori knowledge of the application interfaces. Mappings 206 may be created using an editor, such as an extensible Markup Language (XML) editor or text editor; however, mappings 206 may be created using other means, such as automated tools and the like.
With reference now to FIG. 2B, each adapter may also include a conventional transformation engine, such as transformation engine 262 of adapter 260. Depending upon the implementation, transformation may take place in transformation engine 252 of hub 250, transformation engine 262 of adapter 260, or in both the hub and the adapter. For example, for application 265, some transformation may take place in hub 250 using transformation engine 252 and mappings 256 and some transformation may take place in adapter 260 using transformation engine 262 and mappings 266. In other examples, depending upon the application or the integration design, transformation may take place only in the adapter or only in the hub and this may vary from application to application within a single hub-and-spoke implementation.
Conventional mappings 256, 266 may consist of Java classes, stylesheets, code, or other formats for storing data. Whenever a new application is added in the hub-and-spoke integration scheme, one must only add a spoke to the scheme. Mappings 256 may include mappings for all applications for which transformations take place in the hub, while mappings 266, for example, include mappings only for application 265.
Prior art FIG. 2C illustrates the operation of a conventional hub-and-spoke business integration scheme. Application 1 270 attempts to send data, application specific business object 1 (ASBO) 292, to application 2 280. ASBO 1 292 is converted to generic business object (GBO) 294 through any combination of a transformation engine (not shown) in adapter 1 275 and a transformation engine (not shown) in hub 290. Then, GBO 294 is converted to an application specific business object, ASBO 2 296, for application 2 280 through any combination of a transformation engine (not shown) in adapter 2 285 and a transformation engine (not shown) in hub 290. Thus, application 1 270 sends data in a format expected by application 1 270 and application 2 280 receives data in a format expected by application 2 280. The conventional hub-and-spoke integration model works well if the mappings are correct. However, objects do not map properly from application to application when the mappings are not correct.
As one can see, application integration using the hub-and-spoke model poses significant data integration challenges as compared to the point-to-point model. These challenges spring from the very nature of the hub model and the necessity for a single integrated object model among all applications throughout the integration project. Knowing how each object maps to each application, which objects are used by the applications, and how a new application affects the existing model are difficult problems to be solved in the hub-and-spoke integration scheme. More particularly, when objects do not map properly from application to application, it is difficult to determine where the problem lies. Mappings may be incorrect in the hub or in any adapter in the integration model.
The only existing solution to solve the above problems consists of manual inspection of the object model after manual test runs of each spoke in the model. This solution is labor-intensive and prone to human error.